home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2758 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.5 KB
  1. Path: crc-news.doc.ca!usenet
  2. From: Slobodan Celenkovic <slobodan@cs.unh.edu>
  3. Newsgroups: comp.lang.c++,comp.lang.pascal.delphi.misc
  4. Subject: Re: C++ with Zapp vs. Delphi
  5. Date: 19 Jan 1996 15:39:51 GMT
  6. Organization: The Communications Research Centre
  7. Message-ID: <4doe07$4u8@crc-news.doc.ca>
  8. References: <4coar6$d4n@sun4.bham.ac.uk> <4coip7$69s@news1.usa.pipeline.com> <DBk8wg2yqjbB083yn@iaccess.za> <4d7pmb$48c8@tigger.cc.uic.edu> <4dk38h$gdr@merlin.delphi.com> <4dksp1$3d6c@tigger.cc.uic.edu> <30fe666e.3349285@130.15.126.54> <4dmjt8$6sv@crc-news.doc.ca> <30ff9519.1799465@130.15.126.54>
  9. NNTP-Posting-Host: celenkovic.bob.fob003.ic.gc.ca
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
  14.  
  15.  
  16. dmurdoch@mast.queensu.ca (Duncan Murdoch) wrote:
  17. >Slobodan Celenkovic <slobodan@cs.unh.edu> wrote:
  18. >>
  19. >>No multiple-inheritance, no operator overloading -> Delphi:
  20. >>===========================================================
  21. >>
  22. >>We can't use the abstract item so:
  23. >>
  24. >>class IntItem(some other class);      <- data classes
  25. >>class StringItem(some other class);
  26. >>class MoneyItem(some other class);
  27. >
  28. >Why on earth would you bother to declare those things as classes?  If
  29. >you're writing a descendant of the list class, you just make sure it
  30. >can handle the data directly, without the overhead of putting it in a
  31. >class.
  32.  
  33.  
  34. Object Oriented programming - data hiding, abstraction (see Booch)
  35. The list class shoudln't include any item specific code, otherwise
  36. abstraction principle is broken. I am not going to go into details why
  37. this is bad, see Booch's book.
  38.  
  39.  
  40. >
  41. >>Consequences:
  42. >>
  43. >>- A list class for each item class, hence we end up with twice as many
  44. >>  classes. Furthermore we are placing some (little) item specific code   
  45. >>  into the list class; item specific code really belongs in the item
  46. >>  class!
  47. >
  48. >No, you end up with the same number of classes.  *You* need to write a
  49. >separate class for each item to be put into the list.  *I* need to
  50. >write a separate class for each kind of list.  I don't need to put
  51. >sorting information into items; sorting is what the list does.
  52.  
  53.  
  54. Sorting algorithm is still in the list class (binary search, quick sort,
  55. ..). However the item comparison shouldn't go into the list class, but
  56. item classes. Why? Because items "know" how to compare themselves to
  57. other items. Once again see Booch.
  58.  
  59.  
  60. >
  61. >>- A list may only contain a single type of item. The MI solution's list
  62. >>  can store more than one type of item provided that the appropriate
  63. >>  comparison functions are defined (so a list contain strings, integeres
  64. >>  and money)
  65. >
  66. >Why do you think this?  The list can contain *anything*.  If I did
  67. >decide to put multiple kinds of items into the list, I would probably
  68. >put them in some kind of common container, but I don't need to.  I can
  69. >just do a run-time check of the type of each item.  This would require
  70. >them to be classes, but it wouldn't require them to know they're in
  71. >the list.
  72. >
  73.  
  74.  
  75. Yes, but whenever the item classes change you must go back and change the 
  76. list class. This is exactly what should be avoided. So if you got the 
  77. list class from a vendor in a library you should be able to create new 
  78. item classes and store them in the list without making any changes to the 
  79. list class. This is ideally what we'd want (at least I would). Once you 
  80. implement the list you shouldn't have to go back and change it. So the 
  81. sort method should sort an abstract item class without having to know 
  82. details of item comparison. Again because items change the list must be 
  83. insulated from item internals, including the comparison code.
  84.  
  85.  
  86. >>Finally to put the discussion into perspective. #1 is obviously the best 
  87. >>and most elegant solution. Yet even without MI (Delphi) it is doable. So 
  88. >>the price we pay in Delphi is that the solution is not quite as elegant.
  89. >
  90. >No, I don't think there is really that much difference.  Everything
  91. >I've said above about the "right" way to implement a list would also
  92. >be the "right" way to do it in C++.  I suspect MI has been used for
  93. >this just because C++ has MI, not because it makes sense to implement
  94. >a list that way.
  95. >
  96. >Duncan Murdoch
  97.  
  98.  
  99. Well "the right way" is:
  100. 1) non-OO way which is what we both suggested (I had it as #2 or #3)
  101. 2) OO way using MI (#1)
  102.  
  103. They are both "right", but I still think that the OO way is more elegant. 
  104. Also MI wasn't used just because C++ has it and Delphi doesn't, but 
  105. because of the OO principles! I personaly am not convinced of MI 
  106. necessity, but sometimes it does come in handy, like in this example.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.